Credit card sized electronic devices are known in the art. Finkelstein [U.S. Pat. No. 6,902,116 B (FINKELSTEIN, ALAN) Jun. 7, 2005] discloses a method for making a financial transaction card with embedded electronic circuitry. The method discloses embedding into a card among other things a battery, a switch or an LED. The switch according to Finkelstein is preferably a pressure sensitive switch that may be activated by finger pressure when the card is held between the thumb and index finger.
A particular type of switch is the pusher-type vault switch disclosed in Zieder [WO 2008/129193 A (ZIEDER, DAVID) Oct. 30, 2008]. This switch is particularly suited for use in flexible smart cards because it is extremely thin. The switch of Zieder is an improvement of the prior art in that it is reliable over multiple uses and gives discernable tactile feedback, i.e. the button “clicks” when it is pressed.
Other types of finger-operated switches are known in the art, including resistive switches, which are triggered by the conductivity of a finger bridging two electrical terminals, or by the change in resistivity caused by compressing a pressure-sensitive material; capacitive switches, which are triggered by a change in capacity caused by the proximity of a finger; temperature-sensitive switches, which are triggered by the temperature change caused by the proximity of a finger.
All these types of switches and their equivalents can be used as buttons in the sense of the present invention.
By adding appropriate elements such as an agent for generating client credentials and a display, a credit card sized authentication token can be obtained, such as the “DisplayCard” commercialized by Innovative Card Technologies, Inc. The function of an authentication token is to electronically generate client credentials, also known as one-time passwords, by cryptographically combining a key with at least one of a counter value, a time value, or data entered by the user.
In order to perform authentication, it is essential that the central authentication infrastructure disposes of an equivalent copy of the counter, the time value, or the entered data. Depending on the details of the cryptographic functions used, the central authentication infrastructure either uses this copy to generate a local instance of the client credential for comparison with the received client credential, or it extracts the value of the variable from the received client credential and compares that value with the central copy.
In the case of counter and time based authentication tokens, the central authentication infrastructure will implement a synchronization algorithm to allow successful authentication to occur even if there is a small difference between the variable used by the authentication token and the variable used by the central infrastructure. Such a synchronization algorithm may involve calculating acceptable client credentials corresponding to a range of time or counter values around the time or counter value that is considered correct, or comparing the extracted value to the central copy and assessing whether the difference is within acceptable bounds. These algorithms will lead to successful authentication only if the amount of desynchronization is sufficiently small.
In the case of time-based credential generation, such desynchronization may be due to imperfect clocks. In the case of counter-based credential generation, desynchronization may be due to a number of activations that did not lead to an authentication attempt at the side of the central authentication infrastructure; this could for instance be the effect of a user's repeatedly pressing the authentication token's activation button without submitting the generated credential to the authentication infrastructure.
For an optimal user experience, it is desirable to keep the number of authentication attempts that are unduly rejected, known as false negatives, to a minimum. One class of false negatives which needs to be controlled, is the class of rejections due purely to desynchronization.
At the server side, desynchronization issues can be reduced by making the synchronization algorithm more tolerant, notably by increasing the acceptance range for the counter or time value. However, this comes at the expense of reduced security, because the probability of unduly accepting a forged credential, a so-called false positive, will increase as a consequence. Measures that can be taken to reduce the occurrence of false negatives when using time-based authentication tokens, include using high-precision clocks on both sides.